Website prelaunch checklist

Sam Dutton
5 min readNov 16, 2018

--

Before you launch a website, it’s crucial to check for simple mistakes.

Code

If you don’t have linting in place for all your code, now is the time!

HTMLHint
stylelint
ESLint

These tools can all be used as editor plugins or run from your build process and with continuous integration tools such as Travis.

Accessibility

It’s quick and easy to do an accessibility review that will benefit all your users and reduce the risk of problems post-launch.

If nothing else, run a Lighthouse accessibility audit:

Other tools include Wave, Tenon and axe, all of which can be run programatically or from a browser extension. Make sure to test examples of all relevant content, and not just your home page.

Broken links and images

There are lots of tools to test for broken links or missing images at build and runtime, including Chrome extensions (this one is good) and Node tools.

Broken Link Checker can be used via an API or from the command line:

$ npm install broken-link-checker -g
$ blc http://yoursite.com -ro

Spelling

There are several free tools to check spelling. Aspell is a good one.

Here’s how to check all the Markdown files in your repo (other installation tools are available!):

$ brew install aspell
$ for f in **/*.md; do aspell check $f; done

Alex Chan wrote a great guide that goes into more detail.

Images

It’s easy to end up with images that are poorly compressed or larger in pixel dimensions than necessary. You may also have images that use the wrong format, such as PNG for photos.

One simple technique for checking is to search your repo for images, order by size, then optimise as necessary. Here’s an example on Mac:

This immediately highlights problems. Some images need individual attention — hero.png looks problematic. Open the original asset in an image editor, check the dimensions, compression settings and format (maybe it should be a JPEG?)

Better still, you can use a tool like ImageOptim to optimise all the files in place:

Here’s a screencast of the whole process:

Random glitches

Minor content problems are often repeated. For example, on a site for web developers:

  • Inconsistent capitalisation and spelling: JavaScript not Javascript
  • Inconsistency with spacing before units: 10 MB not 10MB
  • Curly quotes in code samples

You can check manually (search across your repo from your code editor) or write a test script to check for common problems. Web Fundamentals does this really well:

Automated tests are also a great way to maintain an editorial stylesheet: a team standard for spelling, capitalisation and other elements of house style.

Prepare for 404s

There are lots of ways to wind up with 404 errors: pages inadvertently get moved or deleted, and external sites get links wrong. You should prepare for the worst by using analytics.

It’s easy to set up a custom report from Google Analytics to keep tabs on what’s going wrong:

Here’s an example of a report:

Armed with this data, you can fix the most urgent problems and potentially add redirects as a workaround.

Social tags

It’s critical that social sharing tags work properly at launch time.

Google’s structured data testing tool is great for testing:

While you’re at it, make sure everything in your <head> is shipshape: check out Josh Buchea’s HEAD guide.

Performance, SEO, security

The following tools are all useful for quick and easy prelaunch sanity testing:

  • Run Lighthouse and save the report data. You get a quantified baseline and a todo list for improvements.
  • WebPageTest: check performance for different locations and connection types, caching, time to first byte, CDN usage.
  • Chrome DevTools Security panel: HTTPS usage.
  • Chrome DevTools Network Panel: load timings, resource sizes and number of requests. Check for outliers.
  • Chrome Task Manager: if your site constantly uses significant CPU or more memory than other apps then you may need to fix memory leaks, task running or resource loading problems. Make sure to test your site on devices representative of your users.
  • Pagespeed Insights: load performance, data cost and resource usage, including Chrome User Experience report data highlighting real-world performance statistics.
  • Speed Scorecard and Impact Calculator: compare site speed against peers and estimate the potential revenue opportunity of improving site speed.

Lighthouse, WebPageTest and Pagespeed Insights can all be run programatically, so you can integrate testing with your build process.

Google Search Console has a range of tools to ensure your site is discoverable:

Tag Assistant is an extension for troubleshooting Google tags, including Analytics. Google Analytics can also be used to track site speed:

Make sure to test a representative set of content — not just the home page. For example, on an e-commerce site, you might want to test product pages, category pages, search results and the checkout page.

Whatever you do, test your site on a range of devices—make sure to try using a cheap phone and poor connectivity (emulated if necessary). Cajole friends and colleagues to attempt to break your site—fresh eyes find new bugs. Build discount usability testing into your workflow. Simple, iterative user testing, done early, with a few participants, will help avoid expensive mistakes.

If you have other suggestions for prelaunch checks, let me know in the comments!

--

--

Sam Dutton

I am a Developer Advocate for Google Chrome. I maintain simpl.info: simplest possible examples of HTML, CSS and JavaScript. South Australian, living in London.